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(57) Abstract 

The invention concerns a chip card (21) comprising data processing means and main data storage means, wherein the processing 
means include: means for detecting, while the chip card is operating, that the main storage means contain an amount of data such that an 
operation cannot be executed; means for selecting, in the main storage means, a set of data to be unloaded (K), whereof the unloading 
can release in the main storage means a space sufficient for executing said operation; means for unloading the set of data to be unloaded 
(K) into secondary siorage means (23 to 25), in the event said secondary storage means do not contain said data set to be unloaded. The 
invention also concerns the associated communication method and protocol. 
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(57) Abregg 

L'invention concerne une carte a puce (21) comprenant des moyens de traitement de 1'information et des moyens de memorisation de 
Pinformation principaux, dans laquelle les moyens de traitement comprennent: des moyens pour detecter, au cours du fonctionnenient de 
la carte a puce, que les moyens de memorisation principaux contiennent une quantite d 'informations telle que Texecution d'une operation 
n'est pas possible; des moyens pour s61ectionner, dans les moyens de memorisation principaux, un ensemble d' informations a d6charger 
(K), dont le dechargement peut libSrer dans les moyens de memorisation principaux un espace suffisant pour autoriser Texdcution de ladite 
opdration; des moyens pour decharger r ensemble d'informations a ddcharger (K) dans des moyens de memorisation secondares (23 a 25), 
dans le cas ou lesdits moyens de memorisation secondaires ne contiennent pas ledit ensemble d'informations a decharger. L'invention 
concerne aussi le procede et le protocole de communication associes. 
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Titre : 

Carte a puce comprenant des moyens pour gerer une memoire virtuelle, 
proc6de et protocole de communication associes. 

5 La presents invention concerne une carte a puce comprenant des 

moyens pour gerer une memoire virtuelle. 

Depuis une vingtaine d'annee, la carte a puce prend une grande 
place dans la vie courante. Le domaine bancaire s'est interesse le premier 

10 aux cartes a microcircuit : leur principal avantage est de diminuer la fraude. 
Les societes de television a peage et de radiotelephonie les utiiisent comme 
moyen de generation des cles qui servent a chiffrer et dechiffrer des 
emissions cryptees. Pour garantir la securite, il a fallu creer une nouvelle 
architecture de circuit integre. Les cartes de type porte-monnaie 

15 electronique contiennent une somme d'argent electronique ; d'autres cartes, 
dites de fidelite, procurent des avantages financiers a leurs proprietaires. 

On le voit, les appareils en relation avec des cartes a microcircuit 
et plus particulierement les cartes a microprocesseur, sont utilisables dans 

20 un nombre de plus en plus grand ^applications. Au debut, le systeme 
d'exploitation des cartes, c'est a dire le programme situe en memoire ROM, 
ne pouvait gerer qu'une seule application. Le systeme d'exploitation est 
inscrit au moment de la fabrication du micro-circuit. En augmentant la taille 
de la memoire programme (ROM) et de la memoire programmable non 

25 volatile (EPROM et EEPROM, de nos jours FeRAM), le systeme 
d'exploitation peut executer davantage de fonctions. Mais le nombre de ces 
fonctions est toujours limite par la taille de la memoire ROM. De plus, le 
rajout d'une fonction supplementaire dans la ROM implique de realiser un 
nouveau masque ; cette realisation coute tres cher et n'est veritablement 

30 rentabilisee que si une grande quantite de cartes sont concernees. 
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Un moyen d'augmenter le nombre de ces fonctions sans toucher 
a la memoire ROM consiste a ecrire dans la memoire programmable, du 
programme executable ainsi que des donnees permettant de le faire 
fonctionner. II est ainsi possible de rajouter des fonctions supplSmentaires a 
5 un systeme d'exploitation qui ne possede au depart qu'un nombre fige de 
fonctions. La demande de brevet FR-A-2.748.134 decrit un moyen de 
charger du programme dans la memoire programmable. Mais la memoire 
programmable est d'une taille limitee : une fois remplie avec un programme, 
il n'est plus possible de rajouter de fonctions. De plus, le stockage de ce 

10 programme s'effectue au detriment de la place memoire destinee aux 
donnees dans la memoire programmable. Le precedent procede s'utilise 
pour corriger certaines imperfections du programme situe en ROM ou pour 
rajouter quelques autres fonctions. Si une carte doit executer un programme 
d'une taille tres importante, le procede decrit dans ce document peut 

1 5 s'averer insuffisant. 

La presente invention a pour objet de resoudre ce probleme en 
proposant une methode de chargement et dechargement de la memoire 
programmable en fonction des besoins en ce qui concerne les programmes 

20 et/ou les donnees applicatives, pour un dispositif de traitement de 
reformation constitue par une carte. Ainsi, il devient possible a celle-ci 
d'executer des applications tres diverses telles que : Porte-Monnaie 
Electronique, application bancaire, telephonie GSM ou application sante 
actuellement experimentee en FRANCE. A Taide de la presente invention, 

25 les applications qui viennent d'etre enumerees sont virtuellement dans la 
carte. Le proprietaire de la carte les a chargees au prealable ; ainsi, la carte 
est configuree selon ses propres besoins. 

La presente invention permet aussi de resoudre un autre 
30 probleme. Un utilisateur peut avoir besoin d'ouvrir en meme temps deux fois 
une meme application. L'execution de cette application dans un dispositif de 
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traitement de 1'information tel qu'une carte dure un certain temps. Pour 
accelerer le traitement, il est avantageux de pouvoir commencer une 
seconde execution ^application avant la fin de la premiere. Ainsi, le meme 
programme se deroule deux fois en meme temps. 

5 

Le but est atteint par le fait que la carte est dotee d'un systeme 
d'exploitation comprenant au moins trois fonctions : 

- Chargement d'informations applicatives. 

- Dechargement d'informations applicatives. 
1 0 - Execution d'informations applicatives. 

Pour acquerir une nouvelle application, la carte re?oit des 
informations applicatives dans sa memoire programmable et controle ces 
informations. 

Lors d'une commande re?ue d'un lecteur cooperant avec la carte 
15 en vue d'executer une application, le systeme d'exploitation de la carte 
analyse le contenu de sa memoire et determine s'il y a lieu d'appeler le 
reseau pour decharger une partie de sa memoire, et/ou de recharger des 
informations applicatives precedemment dechargees. 

Lors du rechargement d'informations applicatives, le systeme 
20 d'exploitation de la carte verifie que les informations chargees ont ete 
validees par elle dans le passe. Ces informations sont ensuite executees. 

Le reseau peut etre considere comme une extension de la 
memoire programmable de la carte : celle-ci y envoie ce qu'elle ne peut 

25 garder dans sa propre memoire. Elle controle, lors du rechargement, que les 
informations revues du reseau sont bien celles qu'elle avait prealablement 
envoyees. La memoire ROM de la carte doit disposer d'un mecanisme de 
gestion de la memoire programmable qui lui permet de charger et d'executer 
un nombre illimite d'application. Des lors, les tailles des memoires ROM et 

30 programmables de la carte ne sont plus une limitation au nombre 
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d'applications executables, et il n'y a plus besoin cl'effectuer un nouveau 
masquage lors du rajout d'applications. 

En resume, I'invention concerne une carte a puce comprenant des 
moyens de traitement de reformation et des moyens de memorisation de 
5 reformation principaux, caracterisee en ce que les moyens de traitement 
comprennent : 

- des moyens pour detecter, au cours du fonctionnement de la carte a 
puce, que les moyens de memorisation principaux contiennent une quantite 
d'informations telle que I'execution d'une operation n'est pas possible ; 

10 - des moyens pour selectionner, dans les moyens de memorisation 

principaux, un ensemble d'informations a decharger, dont le dechargement 
peut liberer dans les moyens de memorisation principaux un espace suffisant 
pour autoriser I'execution de ladite operation ; 

- des moyens pour decharger I'ensemble d'informations a decharger 
15 dans des moyens de memorisation secondaires, dans le cas ou lesdits 

moyens de memorisation secondaires ne contiennent pas ledit ensemble 
d'informations a decharger. 

[.'invention concerne aussi le procede associe. Elle concerne enfin un 
20 protocole de communication entre une carte a puce et un lecteur de carte a 
puce, la carte comprenant des moyens de traitement de reformation et des 
moyens de memorisation de reformation principaux, caracterise en ce qu'il 
comprend les etapes consistant en ce que : 

-le lecteur transmet a la carte un ordre d'execution d'une operation ; 
25 -la carte recherche si, pour executer cette operation, elle dispose 

d'une place suffisante dans les moyens de memorisation principaux ; 

-dans Taffirmative, la carte execute ladite operation puis transmet un 
compte-rendu d'execution au lecteur ; 

-dans la negative, la carte selectionne dans les moyens de 
30 memorisation principaux un ensemble d'informations a decharger dont le 
dechargement peut liberer dans les moyens de memorisation principaux un 
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espace suffisant pour autoriser I'execution de ladite operation, puis la carte 
decharge Tensemble d'informations a decharger dans des moyens de 
memorisation secondaires en transmettant un ordre de dechargement au 
lecteur, dans le cas ou lesdits moyens de memorisation secondaires ne 
5 contiennent pas ledit ensemble d'informations a decharger, puis elle execute 
ladite operation puis transmet enfin un compte-rendu d'execution au lecteur. 

D'autres details et avantages de la presente invention apparaitront 
au cours de la description suivante de quelques modes d'execution preferes 
10 mais non limitatifs, en regard des dessins annexes sur lesquels : 

La figure 1 represente un reseau de traitement de donnees utilise 
par Tinvention ; 

La figure 2 represente un dispositif de traitement de ('information, 
utilise dans la figure 1 et cooperant avec une carte a puce ; 
15 La figure 3 represente une variante de la figure 2, dans laquelle le 

dispositif de traitement de reformation integre les fonctionnalites de la carte 
a puce ; 

La figure 4 est une variante de la figure 2, ou le dispositif de 
traitement de I'information est equipe d'un dispositif de lecture d'une piste 
20 optique ; et 

La figure 5 represente une variante de ia figure 3. 

Sur la figure 1 , un terminal 20, apte a lire une carte a puce , ou un 
terminal 22 integrant des fonctionnalites de carte a puce cooperent avec des 

25 banques de donnees 23 a 25 distantes et reliees a ceux-ci par un reseau de 
communication de donnees 26. Le reseau de communication de donnees 26 
est notamment un reseau teiephonique, le reseau Internet, ou tout autre 
reseau de communication de donnees. Chaque banque de donnees 
comprend une unite centrale de traitement de donnees gerant une memoire. 

30 Selon Tinvention, et comme precise ci-apres, la carte 21 ou le terminal 22 
peuvent, lorsqu'ils detectent que le chargement d'une nouvelle application 
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dans ceux-ci n'est pas possible en raison d'un manque de place memoire , 
decider de dScharger vers une des banques de donnees 23 a 25 une autre 
application. Ce dechargement libere un espace memoire suffisant pour 
accueillir la nouvelle application. Si la carte 21 ou le terminal 22 ont 
5 ulterieurement besoin de Implication dechargee, ils enverront une 
commande a la banque de donnees correspondante pour recharger 
Tapplication , apres avoir, le cas echeant libere a nouveau de la place 
memoire par un dechargement d' application. 

10 La constitution du terminal 20 et de la carte 21 est precisee sur la 

figure 2, Le terminal comprend de fapon connue en soi un microprocesseur 2 
auquel sont relies une memoire ROM 3, et une memoire RAM 4, des moyens 
5 pour cooperer, avec ou sans contact physique, avec la carte a puce 21 , et 
une interface de transmission 7 permettant au terminal de communiquer avec 

15 le reseau de communication de donnees 26 de la figure 1. Le terminal 20 
peut en outre etre equipe de moyens de stockage te!s que des disquettes ou 
disques amovibles ou non, de moyens de saisie (tels qu'un clavier et/ou un 
dispositif de pointage du type souris) et de moyens d'affichage, ces differents 
moyens n'etant pas represents sur la figure 2. 

20 

Le terminal peut etre constitue par tout appareil informatique installe 
sur un site prive ou public et apte a fournir des moyens de gestion de 
Information ou de delivrance de divers biens ou services, cet appareil etant 
installe a demeure ou portable. II peut notamment s'agir aussi d'un appareil 
25 dedie aux telecommunications. 

Par ailleurs, la carte 21 porte une puce incluant des moyens de 
traitement de reformation 9, une memoire non volatile 10, une memoire 
volatile de travail RAM 14, et des moyens 13 pour cooperer avec le terminal 
30 20. Cette puce est agencee pour definir, dans la memoire 10, une zone 
secrete 11 dans laquelle des informations une fois enregistrees, sont 
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inaccessibles depuis I'exterieur de la puce mais seulement accessibles aux 
moyens de traitement 9, et une zone accessible 12 qui est rendue accessible 
depuis I'exterieur de la puce par le microprocesseur 9 pour une lecture et/ou 
une ecriture d'informations. Chaque zone de la memoire non volatile 10 peut 
5 comprendre une partie non modifiable ROM et une partie modifiable EPROM, 
EEPROM, ou constitute de memoire RAM du type 'flash" ou FRAM (cette 
derniere etant une memoire RAM ferromagnetique), c'est-a-dire presentant 
les caracteristiques d'une memoire EEPROM avec en outre des temps 
d'acces identiques a ceux d'une RAM classique. 

10 

En tant que puce, on pourra notamment utiliser un 
microprocesseur autoprogrammable a memoire non volatile, tel que decrit 
dans le brevet americain n° 4.382.279 au nom de la Demanderesse. Comme 
indique en colonne 1, lignes 13-25 de ce brevet, le caractere 

15 autoprogrammable de la puce correspond a la possibility pour un 
programme fi situe dans une memoire ROM, de modifier un autre 
programme f) situe dans une memoire programmable en un programme gj. 
Dans une variante, le microprocesseur de la puce est remplace - ou tout du 
moins complete - par des circuits logiques implantes dans une puce a semi- 

20 conducteurs. En effet, de tels circuits sont aptes a effectuer des calculs, 
notamment d'authentification et de signature, grace a de I'electronique 
cablee, et non microprogrammee. lis peuvent notamment etre de type ASIC 
(de I'anglais « Application Specific Integrated Circuit »). A titre d'exemple 
d'ASIC, on peut citer le composant de la societe SIEMENS commercialise 

25 sous la reference SLE 4436 et celui de la societe SGS-THOMSON 
commercialise sous la reference ST 1335. Avantageusement, la puce sera 
con<?ue sous forme monolithique. 

Une variante de la figure 2 est illustree sur la figure 3, ou le 
30 terminal 22 de la figure 1 comprend, outre les elements du terminal 20, ceux 
de la carte 21 disposes dans un module 15, les elements communs aux 
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deux figures 2,3 portant les memes references. Toutefois, les moyens de 
cooperation 5,13 de la figure 2 sont remplaces par une liaison permanente 
entre le microprocesseur 2 et le microprocesseur 9. 

5 Une variante de la figure 3 est representee sur la figure 5. Ici, le 

terminal 50 ne comprend qu'un seul microprocesseur 51 ou equivalent , relte 
a une memoire RAM 52 et a une memoire non volatile 53. La memoire non 
volatile 53 comprend une zone 54 rendue accessible de I'exterieur du 
terminal par le microprocesseur 51, et une zone secrete 55 accessible 

10 seulement au microprocesseur 51. Le microprocesseur 51 possede la 
caracteristique autoprogrammable du microprocesseur 9, decrite en relation 
avec la figure 2. Enfin, le terminal 50 possede une interface de transmission 
56 lui permettant de communiquer avec le reseau de communication de 
donnees 26 de la figure 1 . 

15 

La description qui suit fera reference, de fa?on non limitative, a la 
forme de realisation de la figure 2 et le terminal 20 sera denomme 
« lecteur » en raison de sa fonction lecteur de la carte 21 . 

20 Les memoires de la carte sont organisees de la fa?on suivante : 

une memoire de type ROM, une memoire de travail de type RAM, et une 
memoire programmable non volatile de type EEPROM ou FLASH. Comme 
represents sur le tableau 1, la memoire ROM contient une zone de systeme 
Sexploitation de base comprenant au minimum des sous-programmes ou 

25 routines telles que celles d'entree/sortie et d'ecriture/lecture en memoire et 
une zone de systeme d'exploitation d'une memoire virtuelle, cette memoire 
virtuelle etant constitute par la memoire des banques de donnees 23 a 25. 
Le systeme d'exploitation de base et le systeme d'exploitation de la memoire 
virtuelle forment ensemble ce que Ton appellera par la suite le « systeme 

30 Sexploitation de la carte ». 
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Le systeme Sexploitation de la memoire virtuelle est capable de 
gerer de preference au moins neuf commandes. Quatre commandes au 
moins sont lancees par le lecteur vers la carte : 

- Chargement duplications en carte. 

5 - Execution en carte des applications precedemment chargees. 

- Effacement duplications en carte. 

- Controle de presence d'applications en carte. 

Cinq autres commandes sont lancees par la carte vers le lecteur : 

- Dechargement d'applications vers le reseau . 
10 - Rechargement d'applications depuis le reseau. 

- Suspension du processus de chargement . 

- Reprise du processus de chargement. 

- Effacement d'applications dans le reseau. 

Dans une realisation particuliere, le systeme d'exploitation de la memoire 
15 virtuelle filtre et transmet au programme de ('application charge en memoire 
programmable, tous les ordres re?us de I'exterieur qui doivent etre traites 
par ce programme. 

Dans le present texte, le terme « information » designe tout 
20 programme executable ou donnee non executable en general. Le terme 
« application » designe un programme particulier, destine a mettre en 
oeuvre une application d'un fournisseur de services ou de produits, et des 
donnees d'application associees.. 

Toujours selon le tableau 1 , la memoire programmable comporte 
25 au minimum trois zones : 

-une premiere zone dite u des donnees de systeme " contenant un code "C" 
identifiant la carte ; 

-une seconde zone dite « de donnees de gestion » contenant des donnees 
de gestion des applications , a savoir une cle de signature dite " SWAP n 
30 particuliere a chaque carte, une ou plusieurs cles de chiffrement liees selon 
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le cas a des fournisseurs d'applications ou a des applications particulieres, 
et un tableau appete a TAB_APPU et 

-une troisieme zone dite « de chargement », utilisee pour recevoir les 
informations d'applications, c'est-a-dire du programme executable et/ou des 
5 donnee$ necessaires au fonctionnement de ce programme. 

Au depart, la carte peut etre donnee a son porteur avec une zone 
de chargement et un tableau TAB_APPLI vides. Au moins la cle SWAP est 
situee dans la zone secrete 11 de la memoire non volatile 10 de la carte. 

10 



Zone de chargement des informations d'applications 



Zone des donnees de gestion (SWAP, TAB_APPLI, ..) 
Zone des donnees de systeme (code C, .... ) 



Zone du systeme d'exploitation de la memoire virtuelle 

(ROM) 



Zone du systeme d'exploitation de base j 
(ROM) 
Tableau 1 

Le tableau TAB_APPLI contient les informations correspondant 
aux applications disponibles dans la carte, soit que ces applications sont 
15 physiquement contenues en carte , soit qu'elles sont virtuellement 
contenues en carte car dechargees vers le reseau. II a la structure suivante : 
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Code cle 


Adresse de 


nombre 


Signature 


Chargement/ 


I'appiication 


stockage 


d'octets 


des informations 


Dechargement 


I 


ADR-I 


1 


SGN-I 


Charge 


J 


ADR-J 


m 


SGN-J 


Decharge 


K 


ADR-K 


n 


SGN-K 


Charge 


Tableau 2 : 1 


fAB APPLI 



Le tableau TAB_APPL! 2 comprend autant de lignes que duplications 
rendues disponibles par la carte et, pour chaque ligne, cinq colonnes. Une 
5 premiere colonne definit un code d'identification l,J,K de Tapplication. Une 
deuxieme colonne definit une adresse de stockage ADR-I,ADR-J,ADR-K a 
partir de laquelle I'appiication est stockee en carte. Une troisieme colonne 
d6finit un nombre d'octets representant la quantite d'informations de 
('application. Une quatrieme colonne definit une signature portant sur 

10 I'ensemble des octets de ('application , calculee en utilisant un algorithme et 
la cle SWAP de la carte en tant que cle secrete. En tant qu'algorithme , on 
peut utiliser un algorithme symetrique tel que le D.E.S. (de I'anglais Data 
Encryption Standard) ou asymetrique tel que le R.S.A. (des auteurs Rivest, 
Shamir et Adieman) ; avantageusement cependant, il suffira d'utiliser une 

15 fonction plus simple, telle qu'une fonction de hachage comme MD5 ou SHA, 
ou une fonction telle que le « ou exclusif », puisque, dans le cadre de 
I'invention , la signature ne sort pas de la carte et se trouve done preservee. 
Enfin, une cinquieme colonne definit si Tapplication concernee est dans un 
etat « charge » en carte ou « decharge » dans une banque de donnees. 

20 Dans un premier temps, un porteur de carte ou un fournisseur 

d'applications desire charger en carte une premiere application ayant un 
code d'identification " K". L'execution d'une commande de chargement peut 
etre conditionnee par une authentication de porteur ou de fournisseur 
d'applications menee a bien. Le mecanisme d'authentification bien connu en 

25 soi consiste, pour le porteur ou le fournisseur d'applications, a fournir a la 
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carte une information lui permettant de s'assurer qu'elle dialogue avec un 
interlocuteur habilite. 

La commande de chargement contient un ordre de chargement, le 
code C de la carte, le code K de I'application et le nombre d'octets n 
5 d'informations correspondant a cette application, ce qui donne le format de 
commande suivant : 



Ordre de Chargement 


Carte C 


Appli K 


nombre n 


Une fois la commande re?ue 


par la carte, 


le systeme 



10 Sexploitation de la carte verifie que le code C envoye est bien le meme que 
celut enregistre dans la zone des donnees de systeme . Dans la negative, la 
carte renvoie au reseau un message d'erreur. Dans i'affirmative, les 
informations de Implication sont done bien destinees a cette carte : le 
systeme d'exploitation de la carte lit alors le tableau TAB_APPLI dans la 

15 zone des donnees de gestion pour determiner s'il s'agit d'un chargement 
initial ou non. Au depart, TAB_APPLI ne contient pas d'informations sur 
I'application K ; si ce n'est pas le cas, la carte repond au lecteur par le 
message « application deja chargee » ; si e'est le cas, il s'agit done d'un 
chargement initial. Le systeme d'exploitation de la carte determine si les n 

20 octets peuvent etre loges dans sa memoire : dans I'affirmative, elle calcule 
I'adresse de debut " ADR-K " d'un premier bloc de n octets disponibles dans 
la zone de chargement. Dans la negative, elle renvoie le message 
« memoire insuffisante ». Enfin, la carte indique au lecteur qu'il peut envoyer 
les n octets de I'application, a I'aide de la reponse " OK^Chargement \ Le 

25 lecteur envoie alors les n octets de I'application . 

Une fois les informations de Tapplication stockees en memoire 
programmable, le systeme d'exploitation de la carte calcule la signature 
« SGN-K » de ces informations. II rentre alors dans le tableau TAB_APPLI 
30 le code d'application K, I'adresse de stockage ADR-K, le nombre d'octets n, 
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et la signature SGN-K. Une fois cette operation effectuee, I'indicateur 
tt Chargement/Dechargement " est positionne sur " Charge \ La mise a jour 
du tableau TAB_APPLI etant terminee, le systeme d'exploitation de la carte 
peut alors envoyer un compte-rendu, a travers le lecteur, au porteur de carte 
5 ou au fournisseur ^applications, indiquant que le chargement de 
('application a ete correctement effectue. Le tableau TAB_APPLI possede 
alors la structure suivante : 



Code 
de 

Tapplication 


Adresse 

de 
stockage 


N ombre 
d'octets 


Signature 
des 
informations 


Chargement/ 
Dechargement 


K 


ADR-K 


n 


SGN-K 


Charge 


Ta 


bleau 3 : TAE 


I APPLI 



10 

Selon une premiere variante, le systeme d'exploitation de la carte 
peut lancer, juste apres le chargement, le programme executable contenu 
dans les informations applicatives, c'est-a-dire dans les informations de 
('application. Ceci permet d'initialiser les informations applicatives. Par 

15 exemple, dans le cas d'une application Porte-Monnaie Electronique, la 
premiere execution du programme permet d'initiaiiser a 0 Frs le solde du 
porte-monnaie ecrit dans la memoire. Selon une seconde variante, le 
programme executable est lance tors d'une premiere commande envoyee 
par le lecteur a la carte et faisant appel a I'application consideree. De fa?on 

20 simple, I'adresse de debut d'execution de I'application est « ADR-K », mais 
on peut utiliser un adressage indirect : I'adresse designee est alors, de 
fa?on connue en soi dans le domaine des microprocesseurs, le contenu de 
la memoire note [ADR-K] qui contient I'adresse d'execution. 

25 Le lecteur envoie a la carte des commandes en specifiant le type 

duplication ; par exemple, ce type peut etre code dans le premier des cinq 
octets d'une commande selon la norme ISO 7816-3 ; cet octet est appele 
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dans la dite norme : « CLA ». Le systeme d'exploitation de la memoire 
virtuelle de la carte controle les commandes que lui envoie le lecteur et 
determine le code de Implication correspondant a la commande. Puis, il lit 
dans le tableau TAB_APPLI si le code est ecrit ; si c'est le cas, la carte peut 
5 executer I'application K. Si ce n'est pas le cas, la carte ne peut executer 
I'application K : elle repond en envoyant un message d'erreur. Si le code K 
est ecrit dans TAB_APPLI, la valeur de I'indicateur 
« Chargement/Dechargement » est ensuite testee. S'il est positionne sur 
« Chargement », les informations applicatives sont bien presentes en 
10 memoire programmable de la carte. Dans ce cas, le systeme d'exploitation 
de la carte donne la main a un programme de I'application situe a I'adresse 
ADR-K ou [ADR-K]. Nous allons voir par la suite ce qui se passe lorsque la 
m§moire programmable de la carte ne contient pas les informations 
applicatives, parce qu'elles ont deja ete dechargees. 

15 

Supposons maintenant que le porteur de carte ou le fournisseur 
d'applications desire que sa carte contienne les informations d'une seconde 
application, notee « J » par exemple. Cela est possible en chargeant les 
informations applicatives « J » dans la memoire programmable de la carte. 
20 De meme que precedemment, le porteur de carte ou le fournisseur 
d'applications s'authentifie en presentant un secret suivi de la commande de 
chargement d'informations applicatives suivante : 



Ordre de chargement 


Carte C 


Appli J 


nombre m 



25 Elle se presente comme la precedente relative au chargement de 
I'application K ; ici, le nombre d'octets de Tapplication est m. 

Le systeme d'exploitation de la carte verifie le code C et 
recherche le premier bloc de m octets disponible dans la memoire 
30 programmable. Supposons que la memoire programmable ne peut 
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physiquement contenir en meme temps les deux blocs d'informations 
applicatives constitues par I'application K et ('application J, mais qu'elle peut 
contenir I'application J si elle decharge tout ou partie de Tapplication K. La 
carte informe le lecteur qu'elle suspend le processus de chargement de 
5 I'application J a Taide d'une commande specifique envoyee au lecteur, et 
decide alors de decharger ('application K dans une banque de donnees qui 
peut etre consideree comme la memoire virtuelle de la carte. Ce 
dechargement va liberer de la place memoire pour charger I'application J. 

10 Le dechargement consiste alors a transferer dans Tune des 

banques de donnees 23 a 25 du reseau destinee notamment a la carte 
actuelle, les informations applicatives particulieres a cette carte. Par le 
calcul de signature effectue lors du chargement, la carte est assuree de 
pouvoir contrdler I'integrite et ('authenticity de ses propres informations lors 

15 d'un rechargement ulterieur. De plus, le fait d'avoir deja effectue le caicul de 
signature lors du chargement initial optimise le temps d'execution de la 
commande de dechargement. La carte envoie au lecteur la commande 
suivante : 



Ordre de dechargement 


Carte C 


Appli K 


nombre n 


n octets 


vers le reseau 








d'informations 



20 

Cette commande comporte, comme la commande de chargement, 
le code C de la carte, celui K de I'application a decharger ,et le nombre 
d'octets n d'informations de I'application ; elle comporte en plus le contenu 
meme de ces n octets d'informations, transmis au lecteur en meme temps 
25 que I'ordre de dechargement. Dans le cas ou le dechargement de 
I'application intervient alors qu'une partie de celle-ci a deja ete executee, 
des informations de contexte, permettant de-reprendre ulterieurement 
I'execution de I'application a I'endroit ou elle a ete interrompue, sont, soit 
stockees dans la memoire programmable de la carte , soit ajoutees aux n 
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octets conformations de ('application et dechargees en meme temps qu'eux 
dans le reseau. 

II est possible d'indiquer un identifiant de destinataire sous ia 
5 forme d'une adresse de reseau. Avantageusement, le reseau possede une 
table de correspondance qui associe chaque carte a I'adresse de la banque 
de donnee qui lui est notamment destinee. Ceci permet d'eviter a la carte 
d'avoir a stocker ladite adresse ou ledit identifiant, et de rassembler dans 
une meme banque de donnees toutes les informations dechargees a partir 
10 d'une meme carte. 

Le lecteur report la commande, mais reconnait qu'elle est destinee 
au reseau : il la renvoie done vers la banque de donnees a laquelle elle est 
adressee. Si le reseau possede plusieurs banques de donnees, le choix 

15 peut s'effectuer en fonction du code C de la carte. La banque de donnee 
report les n octets d'informations applicatives et renvoie a la carte, via le 
lecteur, un accuse de bonne reception indiquant que le stockage s'est bien 
passe. La carte modifie alors le tableau TAB_APPLI en positionnant 
Tindicateur Chargement/Dechargement sur " Decharge ". La place memoire 

20 occupee jusque-la par les informations applicatives de Implication K 
devient disponible. L'operation de chargement de ('application J peut alors 
reprendre et la carte envoie au lecteur une commande de reprise du 
processus de chargement ; l'operation de chargement s'effectue de fagon 
identique a celle de K. Le systeme d'exploitation de la carte determine 

25 Tadresse de stockage ADR-J des m octets de I'application J et indique au 
lecteur par un message « OK_Chargement » qu'il peut envoyer les rn octets 
d'informations applicatives. 

Le lecteur envoie les m octets d'informations applicatives qui sont 
30 ecrits a partir de I'adresse "ADR-J". Une fois les informations de 
I'application J stockees en memoire programmable, le systeme d'exploitation 
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de la carte calcule une signature de celles-ci en effectuant un calcul 
cryptographique a I'aide de la cle SWAP. Enfin, le systeme d'exploitation 
met a jour le tableau TAB_APPLl en ecrivant le code J, les valeurs ADR-J, m 
et SGN-J, et met a jour I'indicateur u Chargement/Dechargement " en le 
5 positionnant sur u Charge Le systeme d'exploitation peut alors envoyer au 
lecteur un compte-rendu indiquant que le chargement a ete correctement 
effectue. 

Le tableau TAB_APPLI possede alors les valeurs suivantes : 

10 



Code de 


Adresse 


nombre 


Signature 


Chargement/ 


I'application 


stockage 


d'octets 


des donnees 


Dechargement 


K 


ADR-K 


n 


SGN-K 


Decharge 


J 


ADR-J 


m 


SGN-J 


Charge 



tableau 4 : TAB_APPLI 



Une fois terminee la mise a jour du tableau TAB_APPLI, le 
systeme d'exploitation de la carte peut alors lancer ('application J de la 

15 meme fa?on qu'il a lance I'application K et la carte execute la commande 
d'execution que le lecteur lui avait envoyee. 

Si le porteur de carte ou le fournisseur duplications connecte sa 
carte a un lecteur et desire executer une nouvelle fois I'application K, le 
systeme d'exploitation de la carte analyse le contenu du tableau TAB_APPLI 

20 pour determiner si cette application est accessible avec cette carte. Dans le 
cas present, I'application K est bien enregistree dans TAB_APPLI, mais elle 
a ete dechargee dans le reseau. Une autre application est en memoire, c'est 
J et elle occupe m octets. Le systeme d'exploitation teste alors si 
Tapplication K qui occupe n octets en memoire peut etre chargee dans ce 

25 qui reste disponible en memoire. Comme on I'a suppose precedemment, la 
reponse a ce test est negative. Le systeme d'exploitation decide alors de 
decharger I'application J actuelle pour pouvoir recharger I'application K. 
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La commande, emise par la carte, de dechargement vers le 
reseau de J est : 



Ordre de dechargement 


Carte C 


Appli J 


nombre 


m octets 


vers le reseau 






m 


d'informations 



5 



L'operation une fois effectuee, I'indicateur de chargement de 
I'application J dans TAB_APPLI est mis en position « Decharge ». La place 
memoire etant maintenant disponible, le systeme d'exploitation envoie au 
lecteur une commande de rechargement de I'application K depuis le reseau. 
10 Cette commande a le format suivant : 



Ordre de rechargement 


Carte C 


Appli K 


nombre 


a partir du reseau 






n 



Le lecteur recoit la commande et la renvoie vers la banque de 
15 donnee associee a la carte C. La banque de donnee qui possede les 
informations de la carte C recoit la commande et recherche dans le fichier 
de cette carte, les n octets d'informations applicatives relatives a 
I'application K. La banque de donnees elabore le message suivant, qui est 
la reponse a la derniere commande de la carte. Cette reponse est transmise 
20 a la carte via le lecteur : 



Carte C 


Appli K 


nombre n 


n octets de donnees 



25 
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Le systeme Sexploitation de la carte peut verifier que les codes 
C t K et la valeur n resus, sont bien identiques a ceux de la commande de 
dechargement emise precedemment. Si I'identite est realisee, la commande 
se poursuit par la reception des n octets de donnees qui sont ecrits a partir 
5 de I'adresse ADR-K dans la zone de chargement, cette adresse etant a cet 
effet lue par le systeme d'expioitation dans le tableau TAB_APPLI ou 
recuperee a partir des informations de contexte rechargees. Dans le meme 
temps, le systeme d'expioitation calcule la signature des n octets ecrits par 
un calcul cryptographique utilisant la valeur de la cle SWAP. La signature 

10 recalculee est alors comparee a la valeur ecrite dans le tableau TAB_APPLI. 
Si les donnees re?ues du reseau ne sont pas identiques a celles 
dechargees precedemment, les deux valeurs de signature ne seront pas 
egales. II existe alors un doute sur I'authenticite ou Tintegrite des 
informations revues. Les informations chargees ne peuvent done pas etre 

15 executees. La carte renvoie au lecteur un message d'erreur indiquant une 
reception d informations erronees au cours de la derniere operation de 
chargement, et Timpossibilite d'executer Tapplication K ; le systeme 
d'expioitation ne met pas I'indicateur de chargement en position « charge » ; 
le cas echeant, il peut effacer le contenu de I'application K. 

20 

Si en revanche les deux valeurs de signature sont egales, les 
informations re?ues correspondent bien a celles de I'application K 
precedemment chargee dans la carte. Une fois ces controles effectues, le 
systeme d'expioitation de la carte met a jour le tableau TAB_APPLI en 
25 mettant I'indicateur de chargement de I'application K sur la position 
« Charge ». 
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Le tableau TAB_APPLI a alors les valeurs suivantes : 



Code de 


Adresse de 


nombre 


Signature 


Chargement/ 


I'application 


stockage 


d'octets 


des donnees 


Dechargement 


K 


ADR-K 


n 


SGN-K 


Charge 


J 


ADR-J 


m 


SGN-J 


Decharge 



Tableau 5 : TAB_APPLI 



5 Une fois terminee la mise a jour du tableau TAB_APPLI, le 

systeme d'exploitation lance I'application K comme precedemment, et la 
carte peut executer la derniere commande de type applicative envoyee par 
le lecteur. 

10 On a decrit precedemment que, lors de la reception par la carte 

d'une commande de chargement d'une application non actuellement 
stockee, le systeme d'exploitation de la carte teste la place disponible en 
memoire. Si celle-ci est suffisante, le chargement peut s'operer sans 
decharger I'application actuellement en memoire. II existe alors deux 

15 applications dans la carte. Le tableau TAB_APPLI prend alors la 
configuration suivante : 



Code de 


Adresse de 


nombre 


Signature 


Chargement/ 


I'application 


stockage 


d'octets 


des donnees 


Dechargement 


K 


ADR-K 


n 


SGN-K 


Charge 


I 


ADR-I 


i 


SGN-I 


Charge 


J 


ADR-J 


m 


SGN-J 


Decharge 



Tableau 6 : TAB APPLI 



Dans cet exemple, deux applications I et K co-habitent dans la 
20 carte : elles sont directement executables. Une troisieme application J est 
accessible a I'aide de cette carte, mais il faut la recharger a partir du reseau. 
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Les memoires non volatiles de la carte contiennent les informations 
suivantes : 



ADR-K 

Programme de 
I'application K 

Donnees 
de I'application K 



ADR-I 

Programme de I'application 
I 

Donnees 
de I'application I 




Donnees de gestion (cle SWAP, TAB_APPLI,...) 



Donnees de systeme 
(code C.) 



Systeme d'exploitation de la memoire virtuelle 
(ROM) 



Systeme d'exploitation de base 
| (ROM) 

Tableau 7 

5 

Ce tableau correspond au tableau 1 precite, dans lequel ia zone 
de chargement est detaillee comme suit : on voit que la zone de chargement 
des informations applicatives comprend trois sous-zones : une zone 
recevant les informations de I'application K, une zone recevant les 
10 informations de I'application I, et une zone residuelle libre qui est de taille 
inferieure a m. 



A la lumiere de cet exemple, on comprend mieux les 
caracteristiques de I'invention. La carte est dotee d'un systeme d'exploitation 
15 minimum permettant de gerer la place memoire, de charger ou decharger 
des applications, de signer les informations applicatives a decharger vers le 
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reseau, de verifier les informations applicatives dechargees et regues du 
reseau en comparant les signatures, et de lancer des applications chargees 
dans la memoire. La signature permet de verifier que les informations 
applicatives stockees dans la banque de donnees ont bien ete 
5 prealablement chargees dans cette carte. Le lecteur est dote d'un 
programme qui reconnait les commandes de dechargement et rechargement 
de la carte et de moyens pour transmettre les dites commandes au reseau. 
Enfm, le reseau est equipe de banques de donnees, la memoire de ces 
banques pouvant etre consideree comme une extension de la memoire 
1 0 programmable de la carte. 

Comme on Pa vu en preambuie, I'inscription de routines dans la 
memoire programmable pour modifier le fonctionnement du programme en 
ROM ne peut etre realisee que par des personnes connaissant ce 

15 programme. Les sauts vers ces routines et leurs retours dans le programme 
en ROM necessitent de connaltre precisement les adresses, les parametres 
d'entree et de sortie de ces routines, ['utilisation de la memoire de travail, 
..etc. La presente invention resout ce probleme en evitant d'utiliser ces 
routines et, par voie de consequence, de divulguer les specifications de ces 

20 routines, tout en autorisant I'execution de nombreuses applications. Les 
programmes applicatifs s'executent en faisant le moins possible appel au 
programme en ROM. Le concepteur de ce programme peut indiquer les 
points d'entree a certaines routines dites elementaires : reception d'octets, 
emission d'octets, ecriture de n octets en memoire programmable, calcul 

25 cryptographique ...etc. 

Une premiere amelioration de ['invention consiste a chiffrer les 
informations applicatives pour les proteger lors de leurs differents transferts 
entre le dispositif de traitement de reformation destine a accueillir des 
30 applications (tel que la carte 21 ou le terminal 22 de la figure 1 ) et le reseau, 
et lors de leur stockage en dehors de la carte 21 ou du terminal 22. 
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Un premier chiffrement d'application concerne le chargement 
initial de 1'application par un fournisseur d'applications et utilise une cle de 
base secrete, detenue par le dispositif de traitement de 1'information et le 
5 fournisseur d'applications situe dans le reseau ; dans le cas ou le dispositif 
de traitement de rinformation est une carte, son lecteur ignore la cle de 
base. Avantageusement, chaque application est chiffree avec une cle 
diversifiee propre, obtenue a partir de la cle de base et d'un diversifiant 
constitue par un parametre specifique de ('application , par exemple son 
10 code K ou son adresse de stockage ADR-K dans la memoire programmable. 
Ce diversifiant peut etre stocke dans le tableau TAB_APPLI de sorte que le 
systeme d'exploitation peut facilement le retrouver lors des commandes de 
chargement / dechargement. 

15 Lors du chargement initial de ['application par le fournisseur 

d'applications dans le dispositif de traitement de rinformation 21 ou 22, ce 
fournisseur calcule la cle diversifiee associee a cette application et chiffre 
I'application au moyen de celle-ci avant de I'envoyer dans le reseau ; a 
reception, le dispositif de traitement de rinformation calcule la cle diversifiee 

20 associee a cette application et la dechiffre avec celle-ci, avant de la stocker 
dans la zone de chargement de la memoire programmable. 

Un second chiffrement de I'application concerne les 
dechargements et rechargements effectues par le dispositif de traitement de 

25 rinformation 21 , 22. Lors d'un dechargement de Tapplication par le dispositif 
de traitement de rinformation 21,22 vers une banque de donnees, 
I'application est a nouveau chiffree par ce dispositif. La cle de chiffrement 
utilisee n'a pas a etre partagee par le dispositif de traitement de rinformation 
avec tout autre interlocuteur tel que le fournisseur d'applications : n'importe 

30 quelle cle generee par le dispositif de traitement de rinformation conviendra, 
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puisque c'est ce meme dispositif, et lui seul, qui effectuera le dechiffrement 
ulterieun 

Avantageusement, la carte peut utiiiser le procede decrit par le 
5 document US-A-4,907,270 qui a pour objet de fournir un procede pour 
s'assurer de I'authenticite et de I'integrite d'un message chiffre. 

Le chiffrement decrit ci-dessus permet d'eviter que des 
informations applicatives puissent etre decouvertes par un fraudeur, et 
empeche la copie frauduleuse des programmes applicatifs. 

10 

En plus des commandes decrites precedemment, il est possible 
de prevoir deux commandes supplementaires : une commande d'effacement 
^applications, et une commande de controle de presence d'applications en 
carte. 

15 

La commande d'effacement d'applications consiste, pour le 
porteur de carte ou le fournisseur d'applications, a envoyer a la carte une 
commande destinee a supprimer les applications qui ne sont plus utilisees ; 
son format est le suivant : 

20 



Ordre d'effacement 


Carte C 


Appli K 


nombre n 


d'applications 









Elle comprend un ordre d'effacement d'applications, le code C de la carte 
concernee, le code K de Implication, et eventuellement le nombre n 
d'octets d'informations de ('application. Si I'application concernee est 
25 chargee en carte , le systeme d'exploitation de la carte rend disponible 
I'espace memoire reserve jusque-la a I'application K. Si en revanche 
I'application K etait-dechargee dans une banque de donnees, la carte envoie 
vers celle-ci un ordre d'effacement qui a le meme format que celui ci-dessus. 
Enfin, une fois que Tordre d'effacement a ete execute, le systeme 
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Sexploitation efface la ligne du tableau TAB_APPLI concernant cette 
application. 



La commande de controle de presence duplications en carte 
5 peut prendre deux formes differentes. La premiere forme de la commande 
permet au porteur de carte ou au fournisseur duplications de demander a 
la carte si elle possede une application particuliere ; son format est le 
suivant : 



Ordre de controle de 


Carte C 


Appli K 


nombre n 


presence ^applications 









10 



Elle comprend un ordre de controle de presence ^applications, le code C de 
la carte concernee, le code K de ['application, et eventuellement le nombre n 
d'octets d'informations de Implication. 



15 La seconde forme de la commande permet au porteur de carte ou au 
fournisseur d'applications de demander a la carte ('ensemble des lignes de 
son tableau TAB_APPLI , a I'exclusion bien evidemment des signatures et 
eventuellement du nombre n d'octets et de I'indicateur de chargement. Le 
format de la commande est le suivant : 

20 



Ordre de controle de presence d'applications 



Carte C 



Une seconde amelioration de ('invention consiste a ne declencher 
le dechargement d'une application vers le reseau que lorsque cela est 
necessaire. Si, au moment ou il faut liberer de la memoire, I'application 
25 chargee n'a pas ete modifiee et si le reseau possede deja les memes 
informations applicatives de cette application, il n'est pas utile de decharger 
ces informations. La seconde amelioration a pour objet d'eviter de stocker 
plusieurs fois les memes valeurs d'informations applicatives sur le reseau. 
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Pour mettre en place cette amelioration il faut modifier le tableau 
TAB_APPLI, void la nouvelle structure : 



Code de 


Adresse de 


nombre 


Signature 


Chargement/ 


Modification 


Tapplication 


stockage 


d'octets 


des 


Dechargement 










informations 






K 


ADR-K 


n 


SGN-K 


Charge/ 


OUI/ 










Decharge 


NON 



5 Tableau 8 : TAB-APPLI 



On a ajoute une sixieme colonne au tableau, qui contient un 
indicateur note " Modification ", pouvant prendre deux valeurs : Oui ou Non. 
Lors du chargement initial d'une application, I'indicateur est positionne a 

10 " Oui " : cette valeur indique qu'il faut decharger les informations applicatives 
vers le reseau pour liberer la place memoire correspondante. Par contre, 
apres une commande de rechargement a partir du reseau, I'indicateur est 
positionne a " Non " : cette valeur indique que les informations applicatives 
stockees en memoire programmable du dispositif de traitement de 

15 I'information (carte 21 ou terminal 22 de la figure 1) sont identiques a celles 
memorisees dans la banque de donnees du reseau. Tant que I'indicateur 
reste a « Non », le systeme d'exploitation du dispositif de traitement de 
I'information n'effectue pas de commande de dechargement de Tapplication ; 
il positionne uniquement I'indicateur de chargement en position 

20 « Decharge » pour qu'une autre application puisse occuper sa place en 
memoire. L'indicateur est positionne a " Oui " lorsque Ton modifie les 
informations applicatives ; par voie de consequence, la valeur de signature 
n'est alors plus exacte : il faudra la recalculer lors du dechargement. 

25 Cette modification peut intervenir dans au moins deux cas. Le 

premier cas est une mise a jour du programme applicatif, soit pour le rendre 
plus performant en rajoutant des fonctions supplementaires, soit pour 
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corriger un defaut Le second cas arrive frequemment lorsque, dans la 
memoire programmable du dispositif de traitement de I' information 21 ou 22 , 
des donnees sont melees au programme applicatif. Par exemple, une 
application porte-monnaie electronique contient a la fois ie logiciel pour 
5 gerer les debits et les credits, mais aussi des donnees dont le solde. A 
chaque utilisation, cette valeur evolue generalement et done, I'indicateur 
" Modification " est presque toujours en position " Oui 

Ce dernier exemple amene a une troisieme amelioration de la 
10 presente invention. On voit que dans les informations applicatives, existent a 
la fois du programme executable et des valeurs de donnees applicatives 
susceptibles d'evoluer souvent. Les moyens decrits dans la troisieme 
amelioration decrite ci-apres permettent de bien separer les deux types 
d'informations. Le dispositif de traitement de reformation choisit alors de ne 
15 decharger vers le reseau que les informations qu'il a effectivement 
modifiees. 

Pour realiser cette troisieme amelioration, il convient de 
perfectionner ('organisation des memoires non volatiles, qui peut se 
20 schematiser de la fagon suivante : 
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Programme 






de I'application 






(memoire programmable) 










Donnees 


Donnees 




Donnees 


evolutives 


evolutives 




de ['application 


sequence 1 


sequence 2 


Donnees de gesl 


ion (cle SWAP, TAB_APPLI,...) en memoire programmable 



Donnees de type systeme en memoire programmable 
(code C, ) 



Systeme d'exploitation de la memoire virtuelle 
(ROM) 



Systeme d'exploitation de base 
(ROM) 
tableau 9 



Le tableau 9 differe du tableau 1 precite par la structure de sa 
5 zone de chargement de la memoire programmable, qui se presente comme 
suit : 



- un bloc relatif a ^application en tant que telle et comprenant deux sous- 
blocs d' informations : 
10 -un bloc relatif au programme executable de I'application, note 

« programme de I'application » ; 

- un bloc relatif aux donnees (non executables) evolutives de 
Implication, note « donnees de I'application » ; 

-un certain nombre de blocs de donnees (non executables) evolutives 
15 correspondant a des executions particulieres du programme executable : 

ces executions sont appelees par la suite des « sequences ». Par definition, 
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les donnees d'une sequence sont temporaires, c'est-a-dire qu'elles ne sont 
utilisees que lors de cette sequence , et pas lors des sequences 
precedentes ou suivantes. C'est ce qui les distingue des « donnees de 
Tapplication » precitees, lesquelles sont utilisees durant toutes les 
5 sequences. Sur le tableau 9, deux blocs de donnees de sequences sont 
represents, notes « donnees evolutives sequence 1 » et « donnees 
evolutives sequence 2 ». Le role de ces differents blocs d'informations sera 
explique dans I'exemple qui va suivre. 

10 Pour realiser cette troisieme amelioration, le tableau TAB_APPLI 

est modifie, it possede la structure suivante : 



Code 
application/ 
Num6ro de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de Implication 


informations relatives 
aux donnees evolutives 
des sequences not£es « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signatu- 
re 


Charge./ 
D6charge. 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


P/1 


ADR- 
Cod-P 


p-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P/1 


p-dat 


SGN-dat-P/1 


Charge 


P/2 


ADR- 
Cod-P 


p-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P/2 


p-dat 


SGN-dat-P/2 


Charg6 


J/1 


ADR- 
Cod-J 


j-cod 


SGN- 
cod-J 


Charge 


ADR- 
Dat-J/1 


j-dat 


SGN-dat-J/1 


Charge 


J/2 


ADR- 
Cod-J 


j-cod 


SGN- 
cod~J 


Charge 


ADR- 
Dat-J/2 


j-dat 


SGN-dat-J/2 


Decharge 



tableau 10 : TAB_APPLI 

15 

Vis-a-vis du tableau TAB_APPLl 2 precite, ce tableau presente 
les differences suivantes. La premiere colonne specifie, outre le code de 
Tapplication , le numero « i » de la sequence concernee. Les informations 
traitees le sont en deux groupes : celles relatives au programme executable 
20 et aux donnees de Implication , et celles relatives aux donnees evolutives 
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des sequences. Pour chaque groupe d'informations , on retrouve les quatre 
colonnes suivantes du tableau TAB_APPLI 2 : adresse de stockage , 
nombre d'octets , signature , indicateur de chargement. Chaque ligne du 
tableau correspond a une sequence donnee P/1 ou P/2 toutes deux relatives 
5 a une application P, ou une sequence J/1 ou J/2 toutes deux relatives a une 
autre application J. Dans differentes cases du tableau , le code de 
('application est mentionne pour rappeler que la valeur consideree est 
relative a une application donnee ; par exemple : 

• ADR-Cod-P : adresse de stockage relative a i'application P 
10 • j-cod : nombre d'octets relatif a I'application J 

Par ailleurs, le symbole « Cod » indique que la valeur consideree est 
relative a une information de type « application » (programme ou donnees 
du premier groupe), tandis que « Dat » indique que la valeur consideree est 
relative a une information de type « sequence » (donnees du second 
15 groupe) ; par exemple ; 

• SGN-cod-P : signature d'informations (programme ou donnees ) relatives 
a Tapplication P 

• SGN-dat-J/2 : signature de donnees relatives a la sequence N°2 de 
20 ('application J 

Un exemple decrira mieux le probleme pose et la fa?on de le 
resoudre en utilisant la presente invention. 

Le dispositif de traitement de ('information (carte 21 dans ce cas) 

25 vient de recevoir une commande de chargement initial de ('application P : 
application de paiement de type Porte-Monnaie Electronique (PME). Les 
informations applicatives stockees en memoire programmable sont le 
programme executable et les donnees relatives a Tapplication ; il n'y a pas 
encore de donnees evolutives correspondant a une sequence. Ces 

30 informations comprennent n-Cod octets stockes a partir d'une adresse 
ADR-Cod-P. L'indicateur de chargement est positionne a « Charge ». En 
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plus des informations relatives au programme executable et aux donnees de 
I'application, les informations transmises lors de la commande contiennent 
un nombre d'octets de donnees evolutives « p-dat » relatives a une 
sequence i. Le tableau TAB_APPLI possede alors les valeurs suivantes : 

5 



Code 
application 


informations relatives 
au programme executable et 
aux donnees de i'application 


informations relatives 
aux donnees Evolutives 
des sequences notees «c i » 


Num6ro de 
sequence 


adresse 

de 
stockage 


nombre 
d' octets 


signature 


Charg6./ 
D6charg6. 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charg6./ 
D6charg£ 


P/i 


ADR- 
Cod-P 


p-cod 


SGN- 
cod-P 


Charge 


0 


p-dat 


0 


0 



;ableau11 :TAB_APPLI 



Les transactions sont validees par un circuit electronique appele 
module de securite. Ce module peut se situer soit dans le terminal lecteur de 

10 carte 20 de la figure 1, soit, si on desire un maximum de securite, dans un 
centre d'agrement bancaire qui peut se situer tres loin du terminal 20 . Une 
transaction de type P.M.E. se deroule en plusieurs etapes qui necessitent 
des communications entre la carte, le terminal et le module de securite. 
L'achat peut s'effectuer chez un commergant dote d'un terminal avec 

15 module, mais il peut aussi etre fait au domicile du porteur de la carte dont le 
terminal n'est pas dote d'un module. 

La carte est sollicitee pour effectuer un achat par un ordre 
d'initialisation d'une transaction. Le systeme d'exploitation de la carte 

20 reconnait un ordre de type applicatif ; il interroge alors son tableau 
TAB_APPLI. ^interrogation du tableau lui indique que I'application 
correspondant a I'ordre est bien chargee et qu'aucune sequence n'a ete 
aliouee. Le systeme d'exploitation initialise alors une sequence en lui 
attribuant un numero , « 1 » par exemple. II alloue a cette sequence une 

25 place memoire de « n-dat » octets, a partir de Tadresse ADR-Dat-P/1 . 
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L'indicateur de chargement correspondant a cette sequence est positionne 
sur « Charge ». Le tableau TAB_APPLI possede alors les valeurs suivantes 



Code 
application 
/ 


Informations relatives 
au programme executable et 
aux donnees de ('application 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


Numero 


adresse de 


nombre 


signature 


Charge./ 


adresse 


nombre 


signature 


Charge./ 


de 


stockage 


d'octets 




Decharge 


de 


d'octets 




Decharge 


sequence 










stockage 








P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P/1 


n-dat 


0 


Charge 



tableau TAB APPL1 12 



Puis, le systeme Sexploitation de la carte lance le programme 
applicatif en effectuant un saut a I'adresse ADR-Cod-P ; il specifie I'adresse 
ADR-Dat-P/1 des donnees temporaires a utiliser, ce qui permet a 

10 I'application de connaitre I'endroit ou sont memorisees les donnees de la 
sequence. Ces donnees sont, entre autres, le montant de la transaction, 
Tobjet de la transaction, Torganisme vendeur et la date de la transaction. En 
revanche, une donnee telle que le solde du porte-monnaie electronique 
n'est pas une donnee temporaire de sequence, car sa duree de vie depasse 

15 celle d'une sequence ; etant de type applicative, cette donnee est 
memorisee avec le programme de ('application. 



L'achat tfun premier produit est en cours : la carte envoie alors au 
lecteur 20 un message en vue d'obtenir une validation de la transaction 
20 aupres d'un centre de paiement accessible par le reseau. Cette 
communication peut durer un certain temps. En effet, les communications 
peuvent etre perturbees et les donnees envoyees peuvent etre longuement 
analysees par le centre d'agrement bancaire. Tout cela provoque un 
allongement de la duree globale de la transaction. Pendant ce temps, 
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I'utilisateur decide d'effectuer un second achat. La presente invention va 
permettre d'eviter d'attendre la fin de ia premiere transaction pour 
commencer la seconde. 

5 Pour effectuer ce second achat, la carte est sollicttee une 

seconde fois par un nouvel ordre d'initialisation d'une transaction. De meme 
que precedemment, le systeme d'exploitation de la carte verifie que ie 
programme executable de I'application PME est chargee en memoire 
programmable. Cette verification s'effectue en interrogeant son tableau 

10 TAB_APPLI ; le systeme d'exploitation reconnalt alors la presence du 
programme et d'une sequence (1) qui est en cours. Pour cela, il affecte a 
cette seconde execution un nouveau numero de sequence (2) et initialise le 
tableau TAB_APPLI en rajoutant une nouvelle ligne a celui-ci. Puis, il verifie 
s'il existe suffisamment de place pour allouer dans la memoire 

15 programmable n-dat octets pour les informations de types donnees non 
executables. Si la place est suffisante, une nouvelle adresse ADR-Dat-P/2 
est determines et la seconde transaction peut etre lancee. Le tableau 
TAB_APPLI possede les valeurs suivantes : 



Code 
application / 


Informations relatives 
au programme executable et 
aux donnees de ('application 


informations relatives 
aux donnees evolutives 
des sequences notees « j » 


Num6ro de 
sequence 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
D£charge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charg6./ 
D^charg 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P/1 


n-dat 


0 


Charg6 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P/2 


n-dat 


0 


Charge 


tableau 1 


FAB APPL 


13 









Les deux transactions seront alors realisees en parallele dans la 
carte, sans faire appel au reseau. Le lecteur doit indiquer dans les 
commandes applicatives envoyees a la carte, de quelle transaction il s'agit. 
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Si la place est insuffisante, le systeme Sexploitation de la carte 
decide de decharger uniquement les donnees evolutives correspondant a la 
premiere transaction (numero de sequence 1). II calcule alors la signature 
5 des dites donnees de la premiere sequence « SGN-dat-P/1 », et I'inscrit 
dans le tableau TAB_APPLI. Les nouvelles donnees non executables 
pourront ainsi etre a la meme place que les donnees dechargees, c'est-a- 
dire a une adresse commune aux deux sequences et notee ADR-Dat-P. 
Puis, la carte envoie au lecteur la commande suivante : 

10 



Ordre de d^chargement vers 


Carte C 


Appli P - Data - 


nombre 


« n_dat » 


le reseau 




numero de sequence 


n_dat 


octets de 






1 




donnees 



Cette commande est de structure identique a celle precitee, avec la 
difference suivante : la troisieme case contient un parametre specifiant non 
seulement le code P de I'application , mais aussi le fait qu'il s'agit de 
15 donnees de type sequence (par le terme « Data »), et le numero 1 de la 
sequence concernee. 

A la suite de cette commande, le tableau TAB_APPLI possede les 
valeurs suivantes : 

20 



Code 
application / 
Numero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de I'application 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P1 


Decharge 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


0 


Charge 



tableau TAB APPL1 14 
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Suite a cette operation, la seconde transaction portant le numero 
de sequence 2 peut se poursuivre. Cette nouvelle transaction necessite 
aussi une validation de la part du centre de paiement : une demande est 

5 done emise vers le module de securite. Supposons que la carte re^oive a ce 
moment un message de validation de ta premiere transaction. Le systeme 
d'exploitation de la carte reconnalt, a Taide du numero de sequence, que ce 
message concerne une autre transaction que celle en cours et, par la lecture 
du tableau TAB_APPLI, il reconnait la premiere transaction. Pour la traiter, il 

10 doit done charger les donnees non executables de la premiere transaction. 

Sachant que ia place memoire est insuffisante pour les deux blocs 
de donnees, le systeme d'exploitation de la carte doit done decharger les 
donnees de la seconde transaction. II calcule alors la signature des dites 
15 donnees « SGN-dat-P/2 », et I'inscrit dans le tableau TAB_APPLI. Puis, la 
carte envoie au lecteur la commande suivante : 



ordre de dechargement vers 


carte c 


appli p - data - 


nombre 


« n_dat » 


le reseau 




numero de sequence 
2 


n_dat 


octets de donnees 



Le tableau TAB_APPLI possede alors les valeurs suivantes : 

20 



Code 
application / 
Numero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de ('application 


informations relatives 
aux donn6es evolutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charg6./ 
Decharg 
e 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P/1 


Decharg 
e 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P/2 


Decharg 
e 



tableau TAB_APPL1 15 
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Le systeme Sexploitation de la carte envoie alors au lecteur la 
commande suivante : 



Cornmande de rechargement 


Carte C 


Appli P - Data - numero 


nombre 


a partir du reseau 




de sequence 1 


n-dat 



5 



Cette commande differe de la commande de rechargement deja decrite en 
ce que la troisieme case contient un parametre specifiant non seulement le 
code P de ['application , mais aussi le fait qu'il s'agit de donnees de type 
sequence (par le terme « Data »), et le numero 1 de la sequence concernee. 

10 

Le lecteur recoit la commande et la renvoie vers la banque de 
donnee affectee notamment a la carte C. La banque de donnee recherche 
dans le fichier de cette carte, les n-dat octets de donnees non executables 
relatives a I'application P, numero de sequence 1 . La banque de donnees 
15 elabore le message suivant, qui est la reponse a la derniere commande de 
la carte ; cette reponse est transmise a la carte via le lecteur : 



Carte C 


Appli P - Data- numero 


n-dat 


n-dat octets de 




de sequence 1 




donnees 



Cette commande differe de la reponse a une commande de rechargement 
20 deja decrite en ce que la deuxieme case contient un parametre specifiant 
non seulement le code P de I'application , mais aussi le fait qu'il s'agit de 
donnees de type sequence (par le terme « Data »), et le numero 1 de la 
sequence concernee. 

25 Le systeme d'exploitation de la carte peut effectuer une operation 

preliminaire selon laquelle il verifie que les codes C, P, le numero de 
sequence et la valeur n-dat re?us, sont bien identiques a ceux de la 
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commande emise precedemment. Si I'identite est realisee, les n-dat octets 
recus sont memorises a partir de I'adresse ADR-dat-P lue dans le tableau 
TAB_APPLI . Une fois le dernier octet ecrit, le systeme d'exploitation 
recalcule la signature des donnees a I'aide d'un calcul cryptographique 
5 utilisant la valeur de la cle SWAP. La signature recalculee est alors 
comparee a la valeur « SGN-dat-P/1 » ecrite dans le tableau TAB_APPLI. Si 
les deux valeurs de signature ne seront pas egales, les donnees recues du 
reseau sont considerees commee non identiques a celles dechargees 
precedemment. II existe done un doute sur I'authenticite ou I'integrite des 
10 donnees recues. La carte renvoie au lecteur un message d'erreur indiquant 
la reception de donnees erronees au cours de la derniere operation de 
chargement, et I'impossibilite de continuer la transaction. 

Si les deux valeurs sont egales, les donnees recues sont 
15 considerees comme identiques a celles precedemment dechargees par la 
carte : la premiere transaction peut done continuer. Le systeme 
d'exploitation de la carte met ensuite a jour le tableau TAB_APPLI en 
positionnant I'indicateur des donnees de ('application P/1 a « Charge » : 



Code 
application / 


Informations relatives 
au programme executable et 
aux donnees de {'application 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


Numero de 
sequence 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
D§charge 


adresse de 
stockage 


nombre 
d^ctets 


signature 


Charg6./ 
Dechargd 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P/1 


Charg6 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P/2 


Dechargg 


tableau 1 


fAB APP 


LI 16 







La mise a jour du tableau TAB_APPLI etant terminee, le systeme 
d'exploitation lance I'application P qui va continuer la premiere transaction. 
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La premiere transaction etant terminee, 1'execution du programme 
de I'application se termine par un retour au systeme d'exploitation gerant la 
memore virtuelle. Le systeme d'exploitation reconnait alors la fin de la 
5 sequence « 1 » et decide de liberer la place memoire correspondant aux 
donnees de la dite sequence. Pour cela, il efface les informations « adresse 
de stockage », « signature » et I'indicateur de chargement/dechargement en 
les mettant a la valeur zero. 

10 Le tableau TAB APPLI a alors les valeurs suivantes : 



Code 
application / 
Numero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de I'application 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d' octets 


signature 


Charge./ 
Decharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


0 


n-dat 


0 


0 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P/2 


Decharge 


tableau " 


l~AB APPL 


17 



Lorsque la carte re?oit la validation de la seconde transaction, le 
systeme d'exploitation de la carte reconnait, a Taide du numero de 
sequence, que ce message concerne une autre transaction qui n'est pas 
15 chargee. La premiere transaction etant terminee, les donnees non 
executables correspondantes ne sont plus utiles. II n'y a done pas lieu de les 
decharger. II suffit done de charger les donnees non executables 
correspondant a la seconde transaction. Le systeme d'exploitation envoie au 
lecteur la commande suivante : 



Commande de rechargement 


Carte 


Appli P - Data - numero 


nombre 


a partir du reseau 


C 


de sequence 2 


n-dat \ 
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De meme que pour le chargement de la sequence 1, le lecteur 
recoit la commande et la renvoie vers la banque de donnee. La banque de 
donnee recherche, dans le fichier de cette carte, les n-dat octets de donnees 
non executables relatives a I'application P, numero de sequence 2. La 
5 banque de donnees elabore le message suivant qui est transmis a la carte 
via le lecteur : 



Carte C 


Appli P - Data- numero 


nombre 


n-dat octets de 




de sequence 2 


n-dat 


donnees 



Le systeme d'exploitation de la carte peut effectuer une operation 
10 preliminaire selon laquelle il verifie les codes C, P, le numero de sequence, 
et la valeur n-dat recus. Si la verification est conforme, les octets sont ecrits. 
Ensuite, le systeme d'exploitation calcule et verifie la signature des 
donnees. Si les deux valeurs sont egales, les donnees recues sont 
considerees comme identiques a celles precedemment dechargees par la 
15 carte : la seconde transaction peut done continuer. Le systeme d'exploitation 
met a jour le tableau TAB_APPLI en positionnant I'indicateur de chargement 
de I'application P/2 a « Charge » : 



Code 
application / 
Num£ro de 
sequence 


informations relatives 
au programme executable et 
aux donates de ('application 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
D6charge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
D6charg6 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


0 


n-dat 


0 


0 


; P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P/2 


Charge 



tableau TAB APPL 



18 



20 La mise a jour du tableau TAB_APPLI etant terminee, le systeme 

d'exploitation lance I'application P qui va continuer la seconde transaction. 
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La seconde transaction etant terminee, le programme de 
Tapplication se termine par une instruction de retour au systeme 
d'exploitation gerant la memoire virtuelle. Le systeme d'exploitation en 
5 deduit que la sequence « 2 » est terminee ; la place memoire peut alors etre 
liberee. Pour cela, les emplacement, dans le tableau TAB_APPLI, de : 
« adresse de stockage », « signature » et I'indicateur de 
chargement/dechargement sont mis a zero. Le tableau prend les valeurs 
suivantes : 

10 







Informations relatives 


informations relatives 




Code 


au programme executable et 


aux donn6es 6volutives 


application / 


aux donn6es de ('application 


des sequences not&es « i 


» 


Num6ro de 


adresse 


nombre 


signature 


Charge./ 


adresse de 


nombre 


signature 


Charg67 


sequence 


de 
stockage 


d'octets 




Decharge 


stockage 


d'octets 




D6charg6 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


0 


n-dat 


0 


0 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


0 


n-dat 


0 


0 




tableau " 


fAB APPL 


19 



A ce stade, le systeme d'exploitation de la carte peut effacer 
entierement une ligne du tableau TAB_APPLI. La gestion des lignes du 
15 tableau TAB_APPLI s'effectue alors dynamiquement en fonction des 
besoins. 

Une autre methode statique pour gerer le tableau est de decider 
une fois pour toutes le nombre de sequences maximum executables pour 
20 une application : soit « s » ce nombre. « s » est alors transmis lors de la 
commande de chargement initial ^application : le systeme d'exploitation 
reserve dans le tableau TAB_APPLI la place correspondant a ces « s » 
sequences. Prenons par exemple pour s la valeur 2. 
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La commande de chargement de I'application K possdde les 
valeurs suivantes : 



Ordre de Chargement 


Carte C 


Appii K 


nombre n 


s=2 








n-cod 


n-dat 





5 



Cette commande differe de celle decrite precedemment en ce qu'elle inclut 
une cinquieme case definissant la valeur du parametre s. On notera qu'ici la 
commande specifie le nombre n-cod d'octets relatifs a Tapplication et 
envoyes par la commande, et le nombre n-dat d'octets relatifs a chaque 
10 sequence future et reserves a cet usage. En variante, le nombre n-dat 
d'octets peut ne pas etre transmis a ce stade, mais fourni plus tard au 
systeme d'exploitation de la carte par I'application qui y est chargee. 

A la suite de cette commande, le systeme d'exploitation met a jour 
15 le tableau TAB_APPLI avec les valeurs suivantes : 



Code 
application / 
NumSro de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de I'application 


informations relatives 
aux donn6es 6volutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
D6charg6 




ADR- 
Cod-K 


n-cod 


SGN- 
cod-K 


Charge 


0 


n-dat 


0 


0 


k/2 


ADR- 
Cod-K 


n-cod 


SGN- 
cod-K 


Charg6 


0 


n-dat 


0 


0 


tableau 1 


fAB APPL 


20 



20 L'application K peut maintenant etre executee : deux sequences 

sont possibles. 



DOCID: <WO 995340 1A2J_> 



WO 99/53401 



42 



PCT7FR99/00877 



La carte peut parfaitement contenir de fagon virtuelle plusieurs 
applications dotees chacune de plusieurs sequences. Par exemple, void 
une configuration particuliere du tableau TAB_APPLI : 



Code 
application / 
Numero de 
sequence 


informations relatives 
au programme executable et 
aux donnees de ['application 


informations relatives 
aux donnees evoiutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


K/1 


ADR- 
Cod-K 


k-cod 


SGN- 
cod-K 


Decharge 


0 


k-dat 


0 


0 


K/2 


ADR- 
Cod-K 


k-cod 


SGN- 
cod-K 


Decharge 


ADR- 
Dat-K^ 


k-dat 


SGN-dat- 
K/2 


Decharge 


K/1 


ADR- 
Cod-K 


k-cod 


SGN- 
cod-K 


Decharge 


ADR- 
Dat-K/3 


k-dat 


SGN-dat- 
K/3 


Charge 


! J/1 


ADR- 
Cod-J 


j-cod 


SGN- 
cod-J 


Charge 


ADR- 
Dat-J/1 


j-dat 


SGN-dat- 
J/1 


Charge 


J/2 


ADR- 
Cod-J 


j-cod 


SGN- 
cod-J 


Charge 


ADR- 
Dat-J/2 


j-dat 


SGN-dat- 
J/2 


Decharge 



tableau 



AB APPLI 21 



Correspondant a cet exemple, la carte possede virtuellement 
deux applications notees : K et J. Le programme executable de I'application 

10 K n'est pas en zone de chargement ; trois sequences de cette application, 
notees 1,2 et 3, peuvent s'executer en meme temps. La premiere sequence 
est terminee, les deux autres sont en cours d'execution. La sequence 2 est 
dechargee : il faudra done la recharger pour la terminer. De plus, pour 
terminer les sequences 2 et 3, il faudra recharger le programme executable 

15 et les donnees de I'application K. 

Le programme executable de I'application J est en zone de 
chargement ; cette application peut executer en meme temps deux 



WO 99/53401 



PCT/FR99/00877 



43 

sequences, notees 1 et 2, qui sont en cours d'execution. La sequence 2 est 
dechargee : il faudra la recharger pour la terminer. 

De cet exemple, on voit apparaitre la necessite de bien gerer la 
5 place memoire disponible. II faut occuper le plus possible la zone de 
chargement et ainsi eviter le plus souvent les commandes de Dechargement 
et Rechargement. 

Bien evidemment, Amelioration consistant a chiffrer les donnees, 
10 en plus de les signer, lors du dechargement et a les dechiffrer lors du 
chargement/rechargement, peut s'appliquer a cette troisieme amelioration. 

Une amelioration de la procedure de chargement initial d'une 
application en carte consiste a introduce dans la carte une signature des 
15 informations applicatives calculee a partir d'une cle de foumisseur 
d'application. Cette signature permet de s'assurer de Tintegrite des 
informations applicatives et d'authentifier Porigine de ces donnees 
applicatives. 

20 Le chargement initial selon ('amelioration consiste a presenter la 

carte au foumisseur d'application. II est conseille d'effectuer cette operation 
dans les locaux du foumisseur d'application. Ce dernier introduit dans la 
carte sa cle de foumisseur, la signature des informations applicatives, et le 
code de Tapplication, « K » par exemple. Un porteur de la carte effectue une 

25 demande de chargement initial de Tapplication K. Cette demande, qui a ete 
decrite precedemment, peut etre faite a son domicile. Une methode pour 
effectuer de fagon securisee le chargement initial d'une application est 
decrite dans le document FR-A-2.74&134. 

30 Selon une variante de realisation de I'invention , les applications 

stockees en carte ne sont pas dechargees dans une banque de donnees 
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distante, au travers d'un reseau : c'est le lecteur 20 de la figure 2 qui recoit 
et stocke ces applications ; il possede alors a cet effet une memoire 
programmable non volatile dans laquelle sont stockees les applications. Les 
commandes de chargement et de dechargement sont inchangees. Cette 
5 variante est interessante lorsque la carte est introduite toujours dans le 
meme lecteur, par exemple un lecteur situe au domicile du porteur de carte. 

Une autre variante de realisation de I'invention utilise le lecteur de 
carte 40 et la carte a puce 41 de la figure 4, dont les elements communs 

10 avec ceux de la figure 2 portent les memes references. La carte 41 se 
distingue de celie 21 de la figure 2 en ce qu'elle porte une piste optique 42, 
par exemple une piste a ecriture et lecture par rayon laser. Quant au lecteur 
de carte 40, il se distingue de celui 20 en ce qu'il comporte un lecteur de 
piste optique 43, apte a lire et ecrire des informations sur la piste optique 42, 

15 relie au microprocesseur 2 et aux memoires 3,4. 

Selon I'invention , la piste optique 42 est utilisee en tant que 
banque de donnees , au lieu de celles distantes 23 a 25 de la figure 1. En 
pratique, lors du dechargement d'une application depuis la carte 41, la carte 

20 transmet la commande de dechargement au lecteur de carte 40. Le lecteur 
de piste 43 recoit les informations de ('application et les ecrit sur la piste 
optique 42. Lors d'une commande de rechargement, le lecteur de carte 
active le lecteur de piste 43 pour qu'il preleve sur la piste optique 42 les 
informations de I'application : le lecteur de carte transmet ensuite ces 

25 informations au microprocesseur 9 de la carte pour que celui-ci les stocke 
dans la zone de chargement. Les commandes de chargement et de 
dechargement sont toutefois inchangees. 

En variante, la piste optique est remplacee par un autre support a 
stockage de masse, par exemple une piste magnetique. 

30 
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Dans les exemples de realisation precedents, on a decrit un 
dechargem nt duplications depuis un dispositif de traitement de 
reformation vers I'exterieur de celui-ci : dans le cas de la figure 2, la carte 
21 effectuait un dechargement vers le lecteur 20 ou les banques de donnees 
5 23-25 de la figure 1 ; dans le cas de la figure 4, le dispositif de traitement de 
I'information constitue par le microprocesseur 9 et ses memoires 10,14 
effectuait un dechargement vers la piste optique 42. Selon une autre 
variante de realisation de I'invention, un dispositif de traitement de 
I'information effectue un dechargement entre plusieurs memoires de ce 
10 dispositif. Par exemple, ce dispositif de traitement de rinformation est 
constitue par la carte 21 de la figure 2 et le microprocesseur 9 decharge une 
application depuis sa memoire RAM 14 vers sa memoire non volatile 10. 

Par exemple, plusieurs applications K, J sont stockees dans la 
15 memoire non volatile 10. Tout d'abord, I'application K est executee. A cette 
occasion, des informations de travail It,, relatives a I'application K sont 
traitees en memoire RAM, tandis qu'un programme de I'application K reste 
en memoire non volatile 10. Ces informations de travail comprennent 
notamment : 

20 - des variables de travail temporaires, intervenant dans des calculs ; 

- des variables de contexte, permettant a la carte de reprendre 
ulterieurement une execution d'application interrompue ; 

- des sous-programmes. 

A un moment donne, la carte doit executer I'autre application J et, pour cela, 
25 charger des informations de travail Itj dans la memoire RAM. Si la carte 
constate que I'espace libre dans la memoire RAM est insuffisant pour 
recevoir les informations de travail It, , elle decide de stopper I'execution de 
I'application K et de decharger les informations de travail lt k de I'application 
K dans sa memoire non volatile 10. Puis elle execute I'application J en 
30 chargeant les informations de travail Itj associees en memoire RAM. Apres 
execution de I'application J, la carte reprend I'execution de I'application K, a 
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I'endroit ou celle-ci a ete interrompue, en chargeant a nouveau les 
informations de travail lt k en memoire RAM. 

Dans cette derniere variante de ('invention, les commandes de 
chargement et de dechargement ne sont pas utilisees, puisque le dispositif 
de traitement de Information concerne n'a pas a avertir un dispositif externe 
pour effectuer les operations de chargement et dechargement de ses 
memoires. II possede encore un tableau TAB^APPLI, mais celui-ci est 
simplifie par rapport au tableau 2 precite : le parametre « signature des 
informations » est supprime. En effet, les informations ne sortant pas du 
dispositif de traitement de ('information, elles ne risquent pas d'etre alterees 
durant leur dechargement. 

Dans ce qui precede, on a surtout decrit la prise de decision, par 
15 la carte, du dechargement d'un ensemble ^informations, suite a umordre 
regu par la carte de chargement d'un autre ensemble d'informations. On 
rappelle cependant que ('invention couvre aussi le cas ou I'ordre re?u par la 
carte vise a executer une autre operation que le chargement d'un ensemble 
^informations. Par exemple, un traitement particulier demande a la carte 
20 peut requerir une place memoire superieure a I'espace actuellement 
disponible dans la memoire de la carte : il peut s'agir notamment d'un calcul 
cryptographique. Dans ce cas, la carte decidera de decharger un ensemble 
d'informations pour pouvoir executer cette operation. Un autre exemple est 
celui ou Tordre re?u par la carte est un ordre d'execution d'une application K 
25 qui a ete precedemment dechargee de la carte. La carte doit done recharger 
cette application pour Texecuter : si la place memoire est insuffisante pour 
ce rechargement, la carte va decider de decharger une autre application J, 
puis effectuer le rechargement de Implication K. 



5 



10 
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REVINDICATIONS 

1. Carte a puce comprenant des moyens de traitement de reformation 
(9) et des moyens de memorisation de reformation principaux (10,14), 

5 caracterisee en ce que les moyens de traitement comprennent : 

- des moyens pour detecter, au cours du fonctionnement de la carte a 
puce, que les moyens de memorisation principaux (10,14) contiennent une 
quantite d' informations telle que I'execution d'une operation n'est pas 
possible ; 

10 - des moyens pour selectionner, dans les moyens de memorisation 

principaux, un ensemble deformations a decharger (K), dont le 
dechargement peut liberer dans les moyens de memorisation principaux un 
espace suffisant pour autoriser I'execution de ladite operation ; 

- des moyens pour decharger rensemble deformations a decharger 
15 (K) dans des moyens de memorisation secondaires (23 a 25 ; 42 ; 53) , dans 

le cas ou lesdits moyens de memorisation secondaires ne contiennent pas 
ledit ensemble ^informations a decharger. 

2. Carte a puce selon la revendication 1, qui comprend un tableau de 
20 chargement (TAB_APPLI) stocke dans les moyens de memorisation 

principaux et incluant un indicateur de stockage indiquant, pour au moins un 
ensemble d'informations , si celui-ci est stocke ou non dans les moyens de 
memorisation principaux, de sorte que , lorsque les moyens de traitement (9) 
doivent avoir acces audit ensemble d'informations , ils consultent ledit 
25 indicateur de stockage : et 

- dans un premier cas ou I'indicateur de stockage indique que 
rensemble d'informations est stocke , les moyens de traitement accedent a 
celui-ci ; ou 

- dans un second cas ou I'indicateur de stockage indique que 
30 rensemble d'informations n'est pas stocke , les moyens de traitement 
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envoient aux moyens de memorisation secondaires (23 a 25 ; 42 ; 53) une 
commande de chargement de cet ensemble d'informations. 

3. Carte a puce selon la revendication 2, dans laquelle I'indicateur de 
5 stockage comporte un etat « charge » indiquant que Tensemble 

deformations correspondant a ete charge dans la carte a puce a partir des 
moyens de memorisation secondaires (23 a 25 ; 42 ; 53), et un §tat 
« decharge » indiquant que I'ensemble ^informations a ete decharge par la 
carte a puce dans les moyens de memorisation secondaires. 

10 

4. Carte a puce selon la revendication 1 , qui comprend un tableau de 
chargement (TAB_APPLI) stocke dans les moyens de memorisation 
principaux (10,14) et incluant un indicateur de modification indiquant, pour au 
moins un ensemble d'informations dont une premiere version a ete chargee 

15 dans la carte a puce a partir des moyens de memorisation secondaires (23 a 
25 ; 42 ; 53), si cette premiere version a ete modifiee ou non dans la carte a 
puce, de telle sorte que, lorsque cet ensemble d'informations doit etre 
decharge dans les moyens de memorisation secondaires, il n'est 
effectivement decharge que si cette premiere version a ete modifiee. 

20 

5. Carte a puce selon la revendication 1, qui stocke au moins un 
ensemble d'informations en deux parties, a savoir un sous-ensemble 
d'informations duplication (p-cod) contenant un programme et des donnees 
generates de fonctionnement d'une application, et un sous-ensemble 

25 d'informations de sequence (p-dat) contenant des donnees particulieres 
definissant une session particuliere de fonctionnement de I'application , et qui 
comprend des moyens pour detecter que plusieurs ensembles d'informations 
possedent un meme sous-ensemble d'informations d'application (p-cod) et 
des sous-ensembles d'informations de sequence respectifs differents (p-dat), 

30 de sorte qu'il ne stocke dans les moyens de memorisation principaux (10,14) 
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qu'une fois ledit sous-ensemble d'informations d'application et qu'il associe a 
celui-ci chacun desdits sous-ensembles d'informations de sequence. 

6. Carte a puce selon la revendication 5, qui comprend : 

5 - des moyens pour detecter, au cours de son fonctionnement, que les 

moyens de memorisation principaux (10,14) contiennent une quantite 
d'informations telle que le stockage supplemental d'un sous-ensemble 
d'informations de sequence (p-dat) a stocker , associe a un sous-ensemble 
d'informations d'application (p-cod) deja stocke, n'est pas possible ; 

10 - des moyens pour selectionner, dans les moyens de memorisation 

principaux, un sous-ensemble d'informations de sequence a decharger, 
associe au meme sous-ensemble d'informations d'application , dont le 
dechargement peut liberer dans les moyens de memorisation principaux un 
espace suffisant pour autoriser le stockage dudit sous-ensemble 

15 d'informations de sequence a stocker ; 

- des moyens pour decharger ce sous-ensemble dans lesdits moyens 
de memorisation secondaires (23 a 25 ; 42 ; 53), dans le cas ou lesdits 
moyens de memorisation secondaires ne contiennent pas ledit sous- 
ensemble d'informations de sequence a decharger ; et 

20 - des moyens pour stocker dans les moyens de memorisation 

principaux le sous-ensemble d'informations de sequence a stocker. 

7. Carte a puce selon la revendication 5, qui comprend un tableau de 
chargement (TAB_APPLI) stocke dans les moyens de memorisation 

25 principaux et incluant, pour chaque sous-ensemble d'informations 
d'application stocke, un nombre maximum (s) de sequences associees, 
pouvant etre stockees dans les moyens de memorisation principaux. 

8. Carte a puce selon la revendication 1 , qui comprend des moyens 
30 pour recharger dans les moyens de memorisation principaux (10,14) un 
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ensemble d'informations prealablement decharge dans les moyens de 
memorisation secondaires (23 a 25 ; 42 ; 53). 

9. Carte a puce selon la revendication 8, qui comprend un tableau de 
5 chargement (TAB_APPLI) stocke dans les moyens de memorisation 

principaux (10,14) et incluant, pour au moins un ensemble d'informations (K) 
traite par le dispositif, une premiere signature (SGN-K) de cet ensemble 
d'informations calculee par les moyens de traitement (9) avant le 
dechargement eventuel de I'ensemble d'information, avec une cle de 

10 signature (SWAP) stockee dans les moyens de memorisation principaux, les 
moyens de traitement etant agences pour calculer une seconde signature de 
Tensemble d'informations recharge, pour comparer cette seconde signature 
avec la premiere, pour valider le rechargement de I'ensemble d'informations 
dans le cas ou les deux signatures sont identiques, et pour invalider le 

15 rechargement de I'ensemble d'informations dans le cas ou les deux 
signatures sont differentes. 

10. Procede de gestion de la memoire dans une carte a puce 
comprenant des moyens de traitement de reformation (9) et des moyens de 

20 memorisation de Information principaux (10,14), caracterise en ce qu'il 
comprend les etapes consistant a : 

-detecter, au cours du fonctionnement de la carte a puce, que les 
moyens de memorisation principaux (10,14) contiennent une quantite 
d'informations telle que I'execution d'une operation n'est pas possible ; 

25 -selectionner, dans les moyens de memorisation principaux, un 

ensemble d'informations a decharger (K), dont le dechargement peut liberer 
dans les moyens de memorisation principaux un espace suffisant pour 
autoriser I'execution de ladite operation ; 

-decharger I'ensemble d'informations a decharger (K) dans des 

30 moyens de memorisation secondaires (23 a 25 ; 42 ; 53) , dans le cas ou 
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lesdits moyens de memorisation secondares ne contiennent pas ledit 
ensemble d'informations a decharger. 

11. Procede selon la revendication 10, qui comprend les etapes 
5 consistant a : 

- detecter, au cours du fonctionnement de la carte a puce, que les 
moyens de memorisation principaux (10,14) contiennent une quantite 
d'informations telle qu'un stockage supplemental d'un ensemble donne 
deformations prealablement decharge est possible ; 

10 - recharger dans les moyens de memorisation principaux ledit 

ensemble d'informations decharge. 

12. Procede selon la revendication 10, qui comprend les etapes 
consistant a : 

15 - detecter, au cours du fonctionnement de la carte a puce, que les 

moyens de memorisation principaux (10,14) contiennent une quantite 
^informations telle qu'un stockage supplemental d'un ensemble donne 
d'informations prealablement decharge (K) n'est pas possible ; 

- selectionner, dans les moyens de memorisation principaux, un 
20 ensemble d'informations a decharger (J), dont le dechargement peut liberer 

dans les moyens de memorisation principaux un espace suffisant pour 
autoriser le stockage dudit ensemble d'informations prealablement decharge ; 

- decharger ['ensemble d'informations a decharger (J) dans les moyens 
de memorisation secondaires (23 a 25 ; 42 ; 53), dans le cas ou lesdits 

25 moyens de memorisation secondaires ne contiennent pas ledit ensemble 
d'informations a decharger ; et 

- recharger dans les moyens de memorisation principaux ledit 
ensemble d'informations prealablement decharge (K). 

30 13. Procede selon la revendication 10, dans lequel lesdits moyens de 

memorisation secondaires comprennent une banque de donnees (23-25) 
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distante de la carte a puce et reliee a celle-ci par un reseau de transmission 
de donnees (26). 

14. Procede selon la revendication 10, dans lequel lesdits moyens de 
5 memorisation secondaires appartiennent a un dispositif de traitement de 

['information (20) cooperant avec la carte a puce (21). 

15. Procede selon la revendication 10, dans lequel lesdits moyens de 
memorisation secondaires (42;53) appartiennent a la carte a puce. 

10 

16. Protocole de communication entre une carte a puce et un lecteur 
de carte a puce, la carte comprenant des moyens de traitement de 
(Information (9) et des moyens de memorisation de reformation principaux 
(10,14), caracterise en ce qu'il comprend les etapes consistant en ce que : 

15 -le lecteur transmet a la carte un ordre d'execution d'une operation ; 

-la carte recherche si, pour executer cette operation, elle dispose 
d'une place suffisante dans les moyens de memorisation principaux ; 

-dans I'affirmative, la carte execute ladite operation puis transmet un 
compte-rendu d'execution au lecteur ; 

20 -dans la negative, la carte selectionne dans les moyens de 

memorisation principaux un ensemble ^informations a decharger (K) dont le 
dechargement peut liberer dans les moyens de memorisation principaux un 
espace suffisant pour autoriser I'execution de ladite operation, puis la carte 
decharge I'ensemble d'informations a decharger (K) dans des moyens de 

25 memorisation secondaires en transmettant un ordre de dechargement au 
lecteur, dans le cas ou lesdits moyens de memorisation secondaires (23 a 
25 ; 42 ; 53) ne contiennent pas ledit ensemble d'informations a decharger, 
puis elle execute ladite operation puis transmet enfin un compte-rendu 
d'execution au lecteur. 

30 
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17. Protocole selon la revendication 16, dans lequel ladite operation 
est un chargement d'un ensemble tf informations a stocker (J), les etapes 
consistant en ce que : 

-le lecteur transmet a la carte un ordre de chargement dudit ensemble 
5 d'informations a stocker (J) ; 

-la carte recherche si, pour executer cet ordre de chargement, elle 
dispose d'une place suffisante dans les moyens de memorisation 
principaux ; 

-dans I'affirmative, la carte execute I'ordre de chargement puis 
10 transmet un compte-rendu d'execution au lecteur ; 
-dans ia negative, la carte : 

-transmet au lecteur un ordre de suspension du chargement ; 
-selectionne dans les moyens de memorisation principaux un 
ensemble d'informations a decharger (K) dont le dechargement 
15 peut liberer dans les moyens de memorisation principaux un 

espace suffisant pour autoriser I'execution de I'ordre de 
chargement ; 

-decharge I'ensemble d'informations a decharger (K) dans les 
moyens de memorisation secondaires en transmettant un ordre 

20 de dechargement au lecteur, dans le cas ou lesdits moyens de 

memorisation secondaires (23 a 25 ; 42 ; 53) ne contiennent 
pas ledit ensemble d'informations a decharger ; 
-transmet au lecteur un ordre de reprise du chargement ; 
-execute ledit chargement puis transmet un compte-rendu 

25 d'execution au lecteur. 

18. Protocole selon la revendication 16, dans lequel ledit ordre 
d'execution d'une operation consiste, pour le lecteur, a declencher une 
alimentation en energie electrique de la carte. 

30 
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abrege; revendi cations 1,5-9; figures 3-6 
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abrege; revendi cations 1,2,4-7; figure 3 
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CO) 21 septembre 1988 (1988-09-21) 
abrege 

colonne 3, ligne 46 -colonne 4, ligne 35 
colonne 5, ligne 15 - ligne 22; 
revendications 1,2 
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In current systems, users can frequently receive messages indicating that there is insufficient disk 
space to perform the current task. In order to proceed, users must interrupt and exit the current 
task, access a file manager function, and delete files to free up disk space. They must then restart 
the task to continue. This can be a frustrating and time-consuming series of steps. 

A solution is described that would allow user s to clear disk spac e while they are in th e 
current task w ithout having to exit to a file manager functio n t o delete fil es. Two possible imple- 
mentations follow: 

• Manual implementation - in this approach, a dialog box is presented to the user along with a 
message. The dialog gives the user access to files on the current disk. The user has the 
option of deleting files or compressing them to clear disk space. The user simply selects one 
or more files and then selects the delete or compress action. Additionally, the error message 
will indicate to the user how much disk space is needed to continue the task. The dialog box 
will provide feedback to the user on how much disk space is available as the user deletes or 
compresses files. 

• Automatic implementation - in this approach, controlled by options in a Settings function, 
the user can choose for the system to automatically compress files to clear disk space when 
the current task necessitates more space. The user specifies in the Options the appropriate 
algorithm for the system to use in selecting files to compress. Examples might be oldest files, 
largest files, or files with a particular filetype. The system would provide feedback to the user 
with the names of the files as they are compressed. 

Regardless of the implementation, users would require a mechanism to decompress files that 
have been compressed during these operations. Again, there are manual and automatic imple- 
mentations possible. In the manual implementation, file manager functions would include an 
'decompress" action on the action bar for the user to choose. 

In the automatic implementation, the system automatically decompresses a file whenever 
the file was called. If disk space was limited, it would loop to the automatic compression algo- 
rithm discussed above to clear space for the decompression. In this approach, the system is con- 
tinuously looking at the available and needed disk space and compressing and decompressing files 
as needed. 
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